Legacy applications use specific input strings. For example, a method in a legacy application may check an input string for a match to “help”. When matching the string, the legacy application may only match the identical string. For example, “help” would not match “Help”.
Applications may have different versions to support different languages. While an English version of an application may match an input string with “help”, the French version of the application may match an input string with “aide”. The support for different languages may be accomplished using different resource libraries that include the translations of the strings required by the legacy application. The different versions of the legacy application can load and use the appropriate resource library to identify the correct string translation. For example, an English resource library may associate the string “help” with an identifier, such as a number. The French resource library may associate the same identifier number with the string “aide”. The legacy application may then match the input string with the string associated with the identifier in the library that was loaded to use the appropriate string. The resource libraries may be a series of key:value pairs. Depending on the size of the program the resource library is used with, the resource library may have thousands or more key:value pairs. The resource libraries may also be used to provide translation of the strings displayed, for example as output.
New applications may be written to interface with an existing legacy application. For example, a Graphical User Interface (GUI) may be created to interface with an existing legacy system that accepts inputs from a command line. The new applications may be written against one version of a legacy application, but may need to interact with different versions of the legacy application. For example, the new application may provide an English interface based on the English version of the legacy application; however, the new application may also be required to provide a French interface that interfaces with the French version of the legacy application.
The translations required for interacting with the different interfaces, for example “help” and “aide”, may be extracted directly from the source code of the different versions of the legacy application. In order to accomplish this, the behavior of the different versions of the legacy application can be examined and the corresponding source code examined to determine the required strings to use for a particular behavior in the different versions of the legacy application. If resource libraries are used in the legacy application, the source code may be examined to determine the identifier used, and then the resource library used to determine the strings required to interface with the legacy application.
The source code for the legacy application may not be available, or it may be difficult to examine and comprehend in order to determine the translation of the desired strings. It may also be expensive and time consuming to examine all of the code to determine the necessary strings.
There exists tools for aiding developers in internationalizing an application. These tools may for example replace string references found in the source code with identifiers that reference a library that associates the identifier with the string (or its translation). The identifiers and associated strings are typically stored in a file that can be loaded for the correct language version. The tools typically produce a different library for each language the program will be translated to. While the language libraries are useful for internationalizing and localizing an application, they may be large as they comprise all the strings used by the program. For example, strings used to match input commands, strings used to display on buttons, strings used to display as messages, strings of errors, strings on menus etc.